For decades, the use of traditional circuit-based communication networks has declined in favor of packet-based networks, which can be more flexible, efficient, and secure. As a result, the increased popularity of packet-based networking has led to growth in demand for packet-based network devices. This demand has largely been met by manufacturers who create larger and larger monolithic routers to handle an increased volume and complexity of network traffic. However, this model is approaching its technologic and economic limits. It is increasingly difficult to fulfill the increasing performance requirements with traditional router designs, and, with the emergence of low cost data center hardware, router vendors have difficulties justifying the higher costs of hardware for the same performance. At the same time, the demands on the routing and switching control plane in access and aggregation networks are becoming more complex. Operators want the ability to customize routing to handle specific kinds of traffic flows near the edge, configure customized services that span aggregation networks, and achieve multi-layer integration, without the detailed low-level configuration typical of today's networks.
These trends led to a different approach to routing architecture, in which data and control planes are decoupled. With this separation, the control plane may be logically centralized and implemented with a variety of hardware components with varied architectures. Further, the data plane may consist of simplified switch/router elements configured by the logically centralized controller. This new routing split-architecture model focuses on the split of control from forwarding and data processing elements and is at the core of software-defined networking (SDN). One standard for flow processing in software-defined networks is OpenFlow, which defines the protocols used to transport messages between the control plane and the forwarding plane and describes a model for packet processing.
This split-architecture of software-defined networks enables a separation between functionalities that can be logically or physically grouped together. For example, there can be a split or separation between a common control entity and a network application (e.g., Generalized Multi-Protocol Label Switching (GMPLS), Border Gateway Protocol (BGP), Internet Protocol Security (IPSec), etc.). Similarly, there can be a split or separation between control and forwarding/processing (i.e. a separation of central control from network devices performing packet processing). There also can be a split or separation of a data forwarding functionality, a data processing functionality, and a data generation functionality (e.g., Deep Packet Inspection (DPI); Ciphering; Operations, administration and management (OAM); etc.).
Software-defined networks present many advantages over traditional monolithic architecture networks. For example, the control plane applications that implement important network routing and switching functionalities are completely separated from the forwarding plane. Thus, maintaining a centralized control plane enables highly customized and optimized networking services that can be tailored to specific user needs. A centralized control plane provides a highly scalable, reliable, and flexible networking infrastructure that can cater to diverse user needs. The forwarding plane (or data plane) devices can be inexpensive and interchangeable commodity networking devices, which reduces the overall configuration and maintenance burdens for the user. Additionally, a single management and configuration entity for the entire network enhances the ease-of-use experience for users.
However, current SDN configurations also suffer from shortcomings. While systems such as OpenFlow do present valid ways to specify a model for packet processing, a problem exists in that it is very hard to extend or customize this model according to particular routing needs. For example, adding support for new protocols requires proposing changes to the OpenFlow specification, hoping for adoption, and waiting for implementation. Such changes involve modifying the parsing, the classification (since the number of fields to be parsed must have changed) and the actions (e.g., for modifying the header of the new protocol) for the packet processing model.
Another drawback of current SDN packet processing models is that processing specifications require classifying a packet as belonging to a flow based on a static set of protocol header fields. For example, classification may only occur using a limited set of extracted header fields in the form of tuples (e.g., 15 tuples are extracted and used for classification). However, as new protocols are developed, this model cannot be easily updated. Additionally, in some environments, applications may benefit from only partial classification of packets using only a small set of tuples. For example, with MPLS packets, packet-forwarding decisions may be made solely on the contents of short path labels within MPLS headers, without the need to further examine the packet itself. In OpenFlow, it is impossible to classify these packets using fewer than 15 tuples, which is inefficient in terms of parsing effort and flow table memory requirements.
Finally, current SDN models are also weak in processing multiple levels of tunneling (i.e. encapsulation and decapsulation). For example, consider the case of encapsulating an Ethernet packet on top of an Open Systems Interconnection (OSI) model data link layer header (i.e. OSI layer two, or L2) or network layer header (i.e. OSI layer three, or L3), which is often done when implementing Layer 2 Virtual Private Networks (L2VPN) or Pseudo-wires (PW). In this case, it is not possible to use the information found in the headers beyond the first level of L2 or L3 to perform finer grained packet processing.